• Update qs to version 3.0.0 with support for rfc3986 encoding
• Use request's rfc3986 only when using the querystring module
• Add test branch for rfc3986 encoding tests using querystring
• Support for eq, sep and options arguments for querystring
parse and stringify methods via option keys

I was waiting for this PR ljharb/qs#76 to get in to refactor the rfc3986 logic in request. Then this bug report #1593 came out, so this PR is fixing both issues.

At first I tried using querystring.escape for rfc3986 encoding in querystring.stringify

this.lib.escape = function (str) {return this.rfc3986(str)}.bind(this)

But that would affect the global namespace so I opted out for standard wrapping.

Next I had to export the querystring.unescape out of the Querystring module

Querystring.prototype.unescape = querystring.unescape

because it's used in two places in request.js Quick check on the node's code revealed this:

QueryString.unescape = function(s, decodeSpaces) {
  try {
    return decodeURIComponent(s);
  } catch (e) {
    return QueryString.unescapeBuffer(s, decodeSpaces).toString();
  }
};

So probably we can use directly decodeURIComponent in our context, but then again I chose the safer option.

@limbo-lab now you can pass the sep, eq and options arguments to the querystring module like this:

qsStringifyOptions:{sep:';', eq:':', options:{...}}

Let me know what do you think, as there no tests for this behavior yet, and it's not documented in the readme.

Fixes #1593